<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">


<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    
    <title>Django’s release process &mdash; Django 1.7.8.dev20150401230226 documentation</title>
    
    <link rel="stylesheet" href="../_static/default.css" type="text/css" />
    <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
    
    <script type="text/javascript">
      var DOCUMENTATION_OPTIONS = {
        URL_ROOT:    '../',
        VERSION:     '1.7.8.dev20150401230226',
        COLLAPSE_INDEX: false,
        FILE_SUFFIX: '.html',
        HAS_SOURCE:  true
      };
    </script>
    <script type="text/javascript" src="../_static/jquery.js"></script>
    <script type="text/javascript" src="../_static/underscore.js"></script>
    <script type="text/javascript" src="../_static/doctools.js"></script>
    <link rel="top" title="Django 1.7.8.dev20150401230226 documentation" href="../index.html" />
    <link rel="up" title="Django internals" href="index.html" />
    <link rel="next" title="Django Deprecation Timeline" href="deprecation.html" />
    <link rel="prev" title="Django’s security policies" href="security.html" />



 
<script type="text/javascript" src="../templatebuiltins.js"></script>
<script type="text/javascript">
(function($) {
    if (!django_template_builtins) {
       // templatebuiltins.js missing, do nothing.
       return;
    }
    $(document).ready(function() {
        // Hyperlink Django template tags and filters
        var base = "../ref/templates/builtins.html";
        if (base == "#") {
            // Special case for builtins.html itself
            base = "";
        }
        // Tags are keywords, class '.k'
        $("div.highlight\\-html\\+django span.k").each(function(i, elem) {
             var tagname = $(elem).text();
             if ($.inArray(tagname, django_template_builtins.ttags) != -1) {
                 var fragment = tagname.replace(/_/, '-');
                 $(elem).html("<a href='" + base + "#" + fragment + "'>" + tagname + "</a>");
             }
        });
        // Filters are functions, class '.nf'
        $("div.highlight\\-html\\+django span.nf").each(function(i, elem) {
             var filtername = $(elem).text();
             if ($.inArray(filtername, django_template_builtins.tfilters) != -1) {
                 var fragment = filtername.replace(/_/, '-');
                 $(elem).html("<a href='" + base + "#" + fragment + "'>" + filtername + "</a>");
             }
        });
    });
})(jQuery);
</script>


  </head>
  <body>

    <div class="document">
  <div id="custom-doc" class="yui-t6">
    <div id="hd">
      <h1><a href="../index.html">Django 1.7.8.dev20150401230226 documentation</a></h1>
      <div id="global-nav">
        <a title="Home page" href="../index.html">Home</a>  |
        <a title="Table of contents" href="../contents.html">Table of contents</a>  |
        <a title="Global index" href="../genindex.html">Index</a>  |
        <a title="Module index" href="../py-modindex.html">Modules</a>
      </div>
      <div class="nav">
    &laquo; <a href="security.html" title="Django&amp;#8217;s security policies">previous</a>
     |
    <a href="index.html" title="Django internals" accesskey="U">up</a>
   |
    <a href="deprecation.html" title="Django Deprecation Timeline">next</a> &raquo;</div>
    </div>

    <div id="bd">
      <div id="yui-main">
        <div class="yui-b">
          <div class="yui-g" id="internals-release-process">
            
  <div class="section" id="s-django-s-release-process">
<span id="django-s-release-process"></span><h1>Django&#8217;s release process<a class="headerlink" href="#django-s-release-process" title="Permalink to this headline">¶</a></h1>
<div class="section" id="s-official-releases">
<span id="s-id1"></span><span id="official-releases"></span><span id="id1"></span><h2>Official releases<a class="headerlink" href="#official-releases" title="Permalink to this headline">¶</a></h2>
<p>Since version 1.0, Django&#8217;s release numbering works as follows:</p>
<ul class="simple">
<li>Versions are numbered in the form <tt class="docutils literal"><span class="pre">A.B</span></tt> or <tt class="docutils literal"><span class="pre">A.B.C</span></tt>.</li>
<li><tt class="docutils literal"><span class="pre">A.B</span></tt> is the <em>major version</em> number. Each version will be mostly backwards
compatible with the previous release. Exceptions to this rule will be listed
in the release notes. When <tt class="docutils literal"><span class="pre">B</span> <span class="pre">==</span> <span class="pre">9</span></tt>, the next major release will be
<tt class="docutils literal"><span class="pre">A+1.0</span></tt>. For example, Django 2.0 will follow Django 1.9. There won&#8217;t be
anything special about &#8220;dot zero&#8221; releases.</li>
<li><tt class="docutils literal"><span class="pre">C</span></tt> is the <em>minor version</em> number, which is incremented for bug and
security fixes. A new minor release will be 100% backwards-compatible with
the previous minor release. The only exception is when a security or data loss
issue can&#8217;t be fixed without breaking backwards-compatibility. If this
happens, the release notes will provide detailed upgrade instructions.</li>
<li>Before a new major release, we&#8217;ll make alpha, beta, and release candidate
releases. These are of the form <tt class="docutils literal"><span class="pre">A.B</span> <span class="pre">alpha/beta/rc</span> <span class="pre">N</span></tt>, which means the
<tt class="docutils literal"><span class="pre">Nth</span></tt> alpha/beta/release candidate of version <tt class="docutils literal"><span class="pre">A.B</span></tt>.</li>
</ul>
<p>In git, each Django release will have a tag indicating its version number,
signed with the Django release key. Additionally, each release series has its
own branch, called <tt class="docutils literal"><span class="pre">stable/A.B.x</span></tt>, and bugfix/security releases will be
issued from those branches.</p>
<p>For more information about how the Django project issues new releases for
security purposes, please see <a class="reference internal" href="security.html"><em>our security policies</em></a>.</p>
<dl class="glossary docutils">
<dt id="term-major-release">Major release</dt>
<dd><p class="first">Major releases (A.B, A.B+1, etc.) will happen roughly every nine months &#8211;
see <a class="reference internal" href="#id2">release process</a>, below for details. These releases will contain new
features, improvements to existing features, and such.</p>
<p id="internal-release-deprecation-policy">A major release may deprecate certain features from previous releases. If a
feature is deprecated in version <tt class="docutils literal"><span class="pre">A.B</span></tt>, it will continue to work in versions
<tt class="docutils literal"><span class="pre">A.B</span></tt> and  <tt class="docutils literal"><span class="pre">A.B+1</span></tt> but raise warnings. It will be removed in version
<tt class="docutils literal"><span class="pre">A.B+2</span></tt>.</p>
<p>So, for example, if we decided to start the deprecation of a function in
Django 1.7:</p>
<ul class="last simple">
<li>Django 1.7 will contain a backwards-compatible replica of the function which
will raise a <tt class="docutils literal"><span class="pre">RemovedInDjango19Warning</span></tt>. This warning is silent by
default; you can turn on display of these warnings with the <tt class="docutils literal"><span class="pre">-Wd</span></tt> option
of Python.</li>
<li>Django 1.8 will still contain the backwards-compatible replica. This
warning becomes <em>loud</em> by default, and will likely be quite annoying.</li>
<li>Django 1.9 will remove the feature outright.</li>
</ul>
</dd>
<dt id="term-minor-release">Minor release</dt>
<dd><p class="first">Minor releases (A.B.C, etc.) will be issued as needed, often to fix security
issues.</p>
<p class="last">These releases will be 100% compatible with the associated major release,
unless this is impossible for security reasons or to prevent data loss.
So the answer to &#8220;should I upgrade to the latest minor release?&#8221; will always
be &#8220;yes.&#8221;</p>
</dd>
</dl>
</div>
<div class="section" id="s-supported-versions">
<span id="s-backwards-compatibility-policy"></span><span id="supported-versions"></span><span id="backwards-compatibility-policy"></span><h2>Supported versions<a class="headerlink" href="#supported-versions" title="Permalink to this headline">¶</a></h2>
<p>At any moment in time, Django&#8217;s developer team will support a set of releases to
varying levels:</p>
<ul>
<li><p class="first">The current development master will get new features and bug fixes
requiring major refactoring.</p>
</li>
<li><p class="first">Patches applied to the master branch must also be applied to the last major
release, to be released as the next minor release, when they fix critical
problems:</p>
<ul class="simple">
<li>Security issues.</li>
<li>Data loss bugs.</li>
<li>Crashing bugs.</li>
<li>Major functionality bugs in newly-introduced features.</li>
</ul>
<p>The rule of thumb is that fixes will be backported to the last major release
for bugs that would have prevented a release in the first place (release
blockers).</p>
</li>
<li><p class="first">Security fixes and data loss bugs will be applied to the current master, the
last two major releases, and the current <a class="reference internal" href="#lts-releases"><em>LTS release</em></a>.</p>
</li>
<li><p class="first">Documentation fixes generally will be more freely backported to the last
release branch. That&#8217;s because it&#8217;s highly advantageous to have the docs for
the last release be up-to-date and correct, and the risk of introducing
regressions is much less of a concern.</p>
</li>
</ul>
<p>As a concrete example, consider a moment in time halfway between the release of
Django 1.7 and 1.8. At this point in time:</p>
<ul class="simple">
<li>Features will be added to development master, to be released as Django 1.8.</li>
<li>Critical bug fixes will be applied to the <tt class="docutils literal"><span class="pre">stable/1.7.x</span></tt> branch, and
released as 1.7.1, 1.7.2, etc.</li>
<li>Security fixes and bug fixes for data loss issues will be applied to
<tt class="docutils literal"><span class="pre">master</span></tt> and to the <tt class="docutils literal"><span class="pre">stable/1.7.x</span></tt>, <tt class="docutils literal"><span class="pre">stable/1.6.x</span></tt>, and
<tt class="docutils literal"><span class="pre">stable/1.4.x</span></tt> (LTS) branches. They will trigger the release of <tt class="docutils literal"><span class="pre">1.7.1</span></tt>,
<tt class="docutils literal"><span class="pre">1.6.1</span></tt>, <tt class="docutils literal"><span class="pre">1.4.1</span></tt>, etc.</li>
<li>Documentation fixes will be applied to master, and, if easily backported, to
the <tt class="docutils literal"><span class="pre">1.7.x</span></tt> and <tt class="docutils literal"><span class="pre">1.6.x</span></tt> branches.</li>
</ul>
</div>
<div class="section" id="s-long-term-support-lts-releases">
<span id="s-lts-releases"></span><span id="long-term-support-lts-releases"></span><span id="lts-releases"></span><h2>Long-term support (LTS) releases<a class="headerlink" href="#long-term-support-lts-releases" title="Permalink to this headline">¶</a></h2>
<p>Additionally, the Django team will occasionally designate certain releases
to be &#8220;Long-term support&#8221; (LTS) releases. LTS releases will get security and
data loss fixes applied for a guaranteed period of time, typically 3+ years,
regardless of the pace of releases afterwards.</p>
<p>The follow releases have been designated for long-term support:</p>
<ul class="simple">
<li>Django 1.8, supported for at least 3 years after its release (scheduled for
April 2015).</li>
<li>Django 1.4, supported for 6 months after the release of Django 1.8. As
Django 1.8 is scheduled to be released around April 2015, support for 1.4
will end around October 2015.</li>
</ul>
</div>
<div class="section" id="s-release-process">
<span id="s-id2"></span><span id="release-process"></span><span id="id2"></span><h2>Release process<a class="headerlink" href="#release-process" title="Permalink to this headline">¶</a></h2>
<p>Django uses a time-based release schedule, with major (i.e. 1.8, 1.9, 2.0,
etc.) releases every nine months, or more, depending on features.</p>
<p>After each release, and after a suitable cooling-off period of a few weeks,
core developers will examine the landscape and announce a timeline for the
next release. Most releases will be scheduled in the 6-9 month range, but if
we have bigger features to develop we might schedule a longer period to
allow for more ambitious work.</p>
<div class="section" id="s-release-cycle">
<span id="release-cycle"></span><h3>Release cycle<a class="headerlink" href="#release-cycle" title="Permalink to this headline">¶</a></h3>
<p>Each release cycle will be split into three periods, each lasting roughly
one-third of the cycle:</p>
<div class="section" id="s-phase-one-feature-proposal">
<span id="phase-one-feature-proposal"></span><h4>Phase one: feature proposal<a class="headerlink" href="#phase-one-feature-proposal" title="Permalink to this headline">¶</a></h4>
<p>The first phase of the release process will be devoted to figuring out what
features to include in the next version. This should include a good deal of
preliminary work on those features &#8211; working code trumps grand design.</p>
<p>At the end of part one, the core developers will propose a feature list for the
upcoming release. This will be broken into:</p>
<ul class="simple">
<li>&#8220;Must-have&#8221;: critical features that will delay the release if not finished</li>
<li>&#8220;Maybe&#8221; features: that will be pushed to the next release if not finished</li>
<li>&#8220;Not going to happen&#8221;: features explicitly deferred to a later release.</li>
</ul>
<p>Anything that hasn&#8217;t got at least some work done by the end of the first third
isn&#8217;t eligible for the next release; a design alone isn&#8217;t sufficient.</p>
</div>
<div class="section" id="s-phase-two-development">
<span id="phase-two-development"></span><h4>Phase two: development<a class="headerlink" href="#phase-two-development" title="Permalink to this headline">¶</a></h4>
<p>The second third of the release schedule is the &#8220;heads-down&#8221; working period.
Using the roadmap produced at the end of phase one, we&#8217;ll all work very hard to
get everything on it done.</p>
<p>Longer release schedules will likely spend more than a third of the time in this
phase.</p>
<p>At the end of phase two, any unfinished &#8220;maybe&#8221; features will be postponed until
the next release. Though it shouldn&#8217;t happen, any &#8220;must-have&#8221; features will
extend phase two, and thus postpone the final release.</p>
<p>Phase two will culminate with an alpha release. At this point, the
<tt class="docutils literal"><span class="pre">stable/A.B.x</span></tt> branch will be forked from <tt class="docutils literal"><span class="pre">master</span></tt>.</p>
</div>
<div class="section" id="s-phase-three-bugfixes">
<span id="phase-three-bugfixes"></span><h4>Phase three: bugfixes<a class="headerlink" href="#phase-three-bugfixes" title="Permalink to this headline">¶</a></h4>
<p>The last third of a release cycle is spent fixing bugs &#8211; no new features will
be accepted during this time. We&#8217;ll try to release a beta release after one
month and a release candidate after two months.</p>
<p>The release candidate marks the string freeze, and it happens at least two
weeks before the final release. After this point, new translatable strings
must not be added.</p>
<p>During this phase, committers will be more and more conservative with
backports, to avoid introducing regressions. After the release candidate, only
release blockers and documentation fixes should be backported.</p>
<p>In parallel to this phase, <tt class="docutils literal"><span class="pre">master</span></tt> can receive new features, to be released
in the <tt class="docutils literal"><span class="pre">A.B+1</span></tt> cycle.</p>
</div>
</div>
<div class="section" id="s-bug-fix-releases">
<span id="bug-fix-releases"></span><h3>Bug-fix releases<a class="headerlink" href="#bug-fix-releases" title="Permalink to this headline">¶</a></h3>
<p>After a major release (e.g. A.B), the previous release will go into bugfix
mode.</p>
<p>The branch for the previous major release (e.g. <tt class="docutils literal"><span class="pre">stable/A.B-1.x</span></tt>) will include
bugfixes. Critical bugs fixed on master must <em>also</em> be fixed on the bugfix
branch; this means that commits need to cleanly separate bug fixes from feature
additions. The developer who commits a fix to master will be responsible for
also applying the fix to the current bugfix branch.</p>
</div>
</div>
</div>


          </div>
        </div>
      </div>
      
        
          <div class="yui-b" id="sidebar">
            
      <div class="sphinxsidebar">
        <div class="sphinxsidebarwrapper">
  <h3><a href="../contents.html">Table Of Contents</a></h3>
  <ul>
<li><a class="reference internal" href="#">Django&#8217;s release process</a><ul>
<li><a class="reference internal" href="#official-releases">Official releases</a></li>
<li><a class="reference internal" href="#supported-versions">Supported versions</a></li>
<li><a class="reference internal" href="#long-term-support-lts-releases">Long-term support (LTS) releases</a></li>
<li><a class="reference internal" href="#release-process">Release process</a><ul>
<li><a class="reference internal" href="#release-cycle">Release cycle</a><ul>
<li><a class="reference internal" href="#phase-one-feature-proposal">Phase one: feature proposal</a></li>
<li><a class="reference internal" href="#phase-two-development">Phase two: development</a></li>
<li><a class="reference internal" href="#phase-three-bugfixes">Phase three: bugfixes</a></li>
</ul>
</li>
<li><a class="reference internal" href="#bug-fix-releases">Bug-fix releases</a></li>
</ul>
</li>
</ul>
</li>
</ul>

  <h3>Browse</h3>
  <ul>
    
      <li>Prev: <a href="security.html">Django&#8217;s security policies</a></li>
    
    
      <li>Next: <a href="deprecation.html">Django Deprecation Timeline</a></li>
    
  </ul>
  <h3>You are here:</h3>
  <ul>
      <li>
        <a href="../index.html">Django 1.7.8.dev20150401230226 documentation</a>
        
          <ul><li><a href="index.html">Django internals</a>
        
        <ul><li>Django&#8217;s release process</li></ul>
        </li></ul>
      </li>
  </ul>

  <h3>This Page</h3>
  <ul class="this-page-menu">
    <li><a href="../_sources/internals/release-process.txt"
           rel="nofollow">Show Source</a></li>
  </ul>
<div id="searchbox" style="display: none">
  <h3>Quick search</h3>
    <form class="search" action="../search.html" method="get">
      <input type="text" name="q" />
      <input type="submit" value="Go" />
      <input type="hidden" name="check_keywords" value="yes" />
      <input type="hidden" name="area" value="default" />
    </form>
    <p class="searchtip" style="font-size: 90%">
    Enter search terms or a module, class or function name.
    </p>
</div>
<script type="text/javascript">$('#searchbox').show(0);</script>
        </div>
      </div>
              <h3>Last update:</h3>
              <p class="topless">Apr 02, 2015</p>
          </div>
        
      
    </div>

    <div id="ft">
      <div class="nav">
    &laquo; <a href="security.html" title="Django&amp;#8217;s security policies">previous</a>
     |
    <a href="index.html" title="Django internals" accesskey="U">up</a>
   |
    <a href="deprecation.html" title="Django Deprecation Timeline">next</a> &raquo;</div>
    </div>
  </div>

      <div class="clearer"></div>
    </div>
  </body>
</html>